classify arbitrum sequencer inaccessible error as retryable #14100
Conversation
core/chains/evm/client/errors.go
Outdated
| @@ -158,7 +158,7 @@ var arbitrum = ClientErrors{ | |||
| Fatal: arbitrumFatal, | |||
| L2FeeTooLow: regexp.MustCompile(`(: |^)max fee per gas less than block base fee(:|$)`), | |||
| L2Full: regexp.MustCompile(`(: |^)(queue full|sequencer pending tx pool full, please try again)(:|$)`), | |||
| ServiceUnavailable: regexp.MustCompile(`(: |^)502 Bad Gateway: [\s\S]*$`), | |||
| ServiceUnavailable: regexp.MustCompile(`(: |^)502 Bad Gateway: [\s\S]*$|network is unreachable|observed invariant violation on SendTransaction`), | |||
There was a problem hiding this comment.
@dhaidashenko Are these two error messages enough ?
There was a problem hiding this comment.
Do we have some docs we could link for these? because invariant violation on SendTransaction reads like it could be considered Fatal, so we should link any explanation that we can.
There was a problem hiding this comment.
@huangzhen1997 invariant violation is logged by MultiNode when we find contradictions in RPCs responses.
Usually, when we see such log msgs, we need to adjust classification for errors that were logged as Unknown in the resultsByCode field of invariant violation on SendTransaction log.
For this particular case it's network is unreachable and i/o timeout
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
prashantkumar1982
deleted the
BCI-3893/classify-arbitrum-sequencer-error-as-retryable
branch
Cherry-Pick: classify arbitrum sequencer inaccessible error as retryable (smartcontractkit/chainlink#14100) Cherry-Pick: fix unhandled already seen tx error for gnosis chiado (smartcontractkit/chainlink#14099) Requires: “alreadyknown” is properly classified Errors are classified to be Retryable
* add error handling for service unavailable for arbitrum * add changeset * update error message --------- Co-authored-by: Prashant Yadav <[email protected]>
Ticket: https://smartcontract-it.atlassian.net/browse/BCI-3893
Description
In some cases RPCs are not able to reach Arbitrum Sequencer which causes Unknown errors. We should classify them as Retryable. example log
Acceptance Criteria
Errors are classified to be Retryable